With the proliferation of computing devices it is often desirable to network such devices, i.e., communicatively couple such devices, through data networks to facilitate the exchange of information between such devices. In corporate data networks, however, there is often an interest in securing the information resident within a corporate network from intrusion and/or attacks from external third-parties, i.e., attacks through an Internet connection to the corporate intranet. Accordingly, filtering technology, which discriminates between data packets based on the header of each data packet, has been developed to control the passage of packet-based data traffic between networks. Before commercial firewalls became available, network administrators began formulating rules that could be statically applied to filter out unwanted and malicious traffic. However, such static packet filtering had many disadvantages, including allowing external clients to directly connect to internal hosts. An unfriendly user could take over a trusted external host and gain malicious access to the entire internal network with relative ease through the direct connection.
Dynamic packet filtering was developed to solve some of the problems of static packet filtering. Dynamic packet filters allow a temporary “window” in a firewall based on packet header information. The temporary window in the firewall is closed once a series of packets have reached their destination. Since the amount of time the window in the firewall is open is much shorter compared to a static packet filter, many types of attacks that work against a static packet filter are more difficult to deploy against a dynamic packet filter. However, dynamic packet filtering still allows the possibility of direct IP connections between an internal host and an external client.
One emerging application that is typically not supported by conventional corporate firewalls is colloquially referred to as Internet telephony, Internet Protocol (IP) telephony, or “packet telephony:” that is, telephony between networks using IP data packets. One example protocol for packet telephony is formally described in the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) standard entitled, “Draft H.323v4.” As one example packet telephony standard, H.323 specifies the components, protocols, and procedures that provide telephony services, i.e., real-time audio, video, and data communications over packet networks, including IP-based networks. The protocols specified by H.323 are audio codecs; video codecs; subprotocols such as H.225 which defines a call setup sequence based on Q.931 operations including registration, admission, and status (RAS); H.245 control signaling; real-time transfer protocol (RTP); and real-time control protocol (RTCP). However, H.323 is independent of the packet network and the transport protocols over which it runs and does not specify them.
H.323 gateways for telephony traffic between IP networks are known. In this regard, such conventional gateways provide for the translation of protocols for call setup and release, media format conversion between different networks, and the transfer of information between H.323 and non-H.323 networks. In IP telephony, an H.323 gateway may connect an IP network and a circuit-switched network, such as an analog or digital public switched telephone network (PSTN) or an integrated services digital network (ISDN).
However, in the case of packet telephony between networks, it is a well-known problem that the security of a packet telephony exchange is not reliably provided by standard packet protocol firewalls and H.323 gateways. The telephony data packets may appear to the firewall or gateway to be unsolicited insofar as they are streamed from an IP address that has not been targeted by an intranet client and therefore the telephony exchange may be refused. Or, the telephony exchange may be allowed, resulting in a direct connection between a potentially malicious external entity and the intranet client. The potentially malicious external entity then has direct access to the intranet client, and often to the entire intranet.